Remarks 



Claims 1-18 are now pending in the application. Claims 1,3,6,7,9,12,13,15, 
and 18 have been rejected under 35 U.S.C. §102 as being anticipated by Camp. 
Claims 2, 4, 5, 8, 10, 11, 14, 16 and 17 have been rejected under 35 U.S.C. §103 
as being obvious in view of Camp. For at least the reasons stated below, Applicants 
respectfully contend that all claims are in condition for allowance. 

35 U.S.C. § 102 Rejections 

Claims 1,3,6,7,9,12,13,15, and 18 have been rejected under 35 U.S.C. § 102 

as being anticipated by Camp et al. Applicants respectfully traverse these 

rejections. Applicants assert that not every element of every claim, as amended, is 

taught by the reference. MPEP § 2131 provides: 

U A claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art 
reference/' Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 
2 USPQ2d 1051, 1053 (Fed. Cir. 1987). "The identical invention must be 
shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 
1989). The elements must be arranged as required by the claim... 

Independent Claims 1, 7, and 13 

The Examiner rejected independent claim 1 as being anticipated by Camp. 
Camp teaches a method for purchasing goods with electronic money. See The 
Abstract. 

Independent claims 1, 7, and 13 include "receiving from the buyer a form 
indicating the terms of trade utilizing the network." Applicants respectfully disagree 
with the Examiner's characterization of the Camp reference. Camp teaches that the 
customer identifies a desire to make a purchase. See Camp, Col. 7, Lines 45-46. 
There is no form that is received from the buyer that indicates the terms of trade 
utilizing the network. 

Independent claim 1 further recites "sending the form to a bank for assessing 
the credit of the buyer utilizing the network, wherein the bank to which the credit 
application is sent is based on the identifier." First, Camp at most suggests 
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transmitting customer payment data, not a form indicating the terms of trade. See 
Figure 1. Second, Camp does not teach or suggest that the bank illustrated in 
Figure 1 assesses credit of the buyer. Camp at most teaches that the bank can 
read encrypted customer data. See Col. 8, Lines 15-26. Camp does not disclose a 
credit assessment done by the bank. Third, Camp does not teach sending the form 
to a bank which is based on the identifier. Finally, Camp does not teach forwarding 
the form to a seller along with the assessment of the credit of the buyer utilizing 
the network. Camp does not teach forwarding a form because, as discussed above, 
there is no form to forward. Further, Camp does not teach forwarding an 
assessment of the credit of the buyer because there is no credit assessment of the 
buyer. Therefore, Applicants respectfully request that these rejections be 
withdrawn. 

The rejections of dependent claims 3 and 6 should also be withdrawn 
because these claims depend from independent claim 1. The rejection of 
independent claim 7 should also be withdrawn because this claim recites similar 
limitations to independent claim 1 in the form of a computer program embodied on 
a computer readable medium. The rejection of dependent claims 9 and 12 should 
also be withdrawn because these claims depend from independent claim 7. The 
rejection of independent claim 13 should be withdrawn because this claim recites 
similar limitations to independent claim 1 in the form of a system. The rejections of 
dependent claims 15 and 18 should also be withdrawn because they depend from 
independent claim 13. 

Because not every element of every claim (as amended) is taught by the 
reference, the Examiner's § 102 rejections are unsupported by the art and should 
be withdrawn. 

35 U.S.C. § 103 Rejections 

Claims 2, 4, 5, 8, 10, 11, 14, 16 and 17 have been rejected under 35 U.S.C. 
§ 103 as being unpatentable over Camp, et al. Applicants respectfully traverse 
these rejections. MPEP § 2143 provides in part, "To establish a prima facie case of 
obviousness ... the prior art reference ... must teach or suggest al! the claim 
limitations." (emphasis added). The recent decision of the U.S. Court of Appeals 
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Federal Circuit of In Re Lee , 61 USPQ2d 1430, is particularly pertinent to this issue. 
At page 1433 the Court addresses the purpose of the Administrative Procedure Act 
which requires administrative agencies, including the Patent Office, to not only have 
reached a sound decision, but to have articulated the reasons for that decision. 
This applies to patent prosecution in the office and before the board and 
subsequent review. In addressing the issue of obviousness the Court noted that 
rejections under 35 USC § 103 must be based on evidence comprehended by 
language of the Section. The Court cites a series of cases requiring the showing of a 
suggestion, teaching or motivation to combine prior art references as an essential 
component to an obviousness holding. The Patent Office Board of Appeals in the 
Lee matter had rejected the need for any specific hint or suggestion in a particular 
reference to support the combination of prior art teachings. The Board had relied 
upon basic knowledge or common sense. In essence, the Federal Circuit required 
that there be evidence of the showing of a suggestion, teaching or motivation to 
combine the state of the art including what might be considered basic knowledge or 
common sense to combine or modify references. Because this showing has not 
been made, Applicants respectfully request that the Examiner's §103 rejections also 
be withdrawn. 

Applicants further submit that all of these dependent claims are allowable 
because they depend from independent claims that recite limitations not disclosed 
in the prior art, as discussed above. Applicants respectfully request that the 
Examiner withdraw these rejections. 

Specification 

Applicants have reviewed the Specification for clerical errors and have 
amended the Specification to correct errors that were noted. The marked changes 
are shown on the attached pages entitled "Version with Markings to Show Changes 
Made". Additions have been noted by underlining an addition . Deletions have been 
noted by placing a strike through on a de l et i on . 

Conclusions 
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Applicants submit that all pending claims are allowable and respectfully 
requests that a Notice of Allowance be issued in this case. In the event a telephone 
conversation would expedite the prosecution of this application, the Examiner may 
reach the undersigned at (310) 788-5053. If any fees are due in connection with 
the filing of this paper, then the Commissioner is authorized to charge such fees 
including fees for any extension of time, to Deposit Account No. 50-1901 
(Reference 60021-339201). 



Respectfully submitted, 



Dated: January 8, 2003 




Douglas/lM. larsonV^eg. No. 29,401 
Customer No\ 29838 

i 

OPPENK1EIMER WOLFF & DONNELLY LLP 
1400 Pag-e'Mill Road 
Palo Alto, CA 94304 
Phone: (310) 788-5053 
Fax: (310) 788-5100 
E-mail: dlarson@oppenheimer.com 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 

In The Specification 

Please incorporate the following replacement paragraphs in the subject 
application specification. 

Page 8, lines 12-13 

Figure 14 expands on the bidding process of the VTrade system discusses 
discussed above with reference to Figure 13; 

Page 9, lines 9 

Figures 24A and 24B illustrate a Purchase Order Pe rforma Proforma Invoice 
(POPI); 

Page 9, line, 11 

Figure 25 depicts a combined Purchase Order P e rform a ■Prof orma..In voice; 

Page 9, lines, 13-17 

Figure 27 illustrates the Main Menu Page of an electronic document checklist 
which may be used during the process of Figure 26; 

Figure 28 is a flowchart illustrating a process for creating a financial 
transaction-related document; 

Page 9, lines 30-31 through Page 10, lines 1-2 

Figure 34 illustrates a third option of documentary compliance in which the 
buyer checks physical documents while VTrade checks electronic documents; 

Figure 35 illustrates a general architecture of the VTrade system, including a 
buyer station, a seller station, a processing hub, and a credit provider system; 

Page 12, lines 1-3 
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Figure 59 illustrates an embodiment of the present invention provides-that 
offers an integrated package of eEnabled financial services products in one or more 
of the five categories; 

Page 13, lines 10-11 

Figure 72 is a flowchart i4l iJ 5 t fa te S"i!Justrating,a process for initiation of an 
agreement utilizing a network; 

Page 18, lines 4-10 

Virtual Trading (VTrade) is a ''method" of conducting the trade finance 
business that achieves the same results as traditional trade finance through a new 
value proposition and a rethought process. In the VTrade operating model, 
physical documents are reduced. The number of parties involved are kept to the 
m i n i mQ l minimum . Three key components of VTrade model are: - VTrade Enterprise, 
Payment Network and a Bank. It should be noted that though "Bank" is used 
throughout this document, it is intended that the term include any type of credit 
provider. 

Page 19, lines 8-12 

• Navigation services that help users to be informed and guided towards the 
various services and trade partners 

• Communities users interacting with one another will quickly transform 
their relationship to become a community, as buyers and sellers find 
themselves sharing common needs and/or business processes 

Page 19, lines 17-21 

• Unique Payment Rules Introduces a unique hybrid of e-Commerce and 
Vtea -VISA Card payment rules for quicker dispute resolution for the 
international trading community 
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• Trade FacilitationUnleashes the power of trade facilitation to ensure that 
majority of trade transactions are settled using the electronic trade 
facilitation engine 

Page 19, lines 26-29 

• International Trading Unlike other offerings, VTrade does not focus only 
on local or regional trade, but also on international trading, with a range of 
supporting facilitation services which will help Visa -VISA Members to develop 
a range of additional revenue sources from repeat business 

Page 20, lines 1-6 

• Innovative Product OfferingsFocuses on core Trade Finance business 
supported by other innovative product offerings developed exclusively for 
Visa- VISA Members. VTrade has treasury and cash management product 
capability built-in 

• Strategic Partnership Improve business connectivity of companies 
through vast global network, riding on the reliable network of Visa- VISA and 
international banks 

Page 30, lines 7-11 

• Encapsulation enforces data abstraction through the organization of data into 
small, independent objects that can communicate with each other. 

• Encapsulation protects the data in an object from accidental damage, but 
allows other objects to interact with that data by calling the object's member 
functions and structures. 

Page 38, lines 14-15 

Figure 12 illustrates a process for application for access to the VTrade 
system by a seller/merchant 1200. Numbers 1-7 enumeration- enumerate the 
steps of the process. 

Page 40, lines 8-20 
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Figure 16 is a flow diagram which expands on the process of Figure 15. In 
operation 1600, it is determined that a buyer and seller have agreed to transact on 
VTrade. In operation 1602, an invoice, in this example a purchase order proforma 
invoice (POPI), is received from the buyer and authenticated before being sent to 
the seller. See the discussion of Figures v23 a nd - 21 23, 24A, and 24B below for a 
description of the POPI. A request for a credit check is sent to the bank (or credit 
provider) in operation 1604. The buyer's credit line is also earmarked in operation 
1606 to indicate the amount of the purchase order to prevent the buyer from 
exceeding the maximum amount of credit. In operation 1608, the seller is alerted 
to start negotiating on the invoice. The initiation of negotiation is confirmed in 
operation 1610. The buyer is alerted that the seller acknowledges the transaction 
in operation 1612. In operation 1614 and 1616, a negotiation about the invoice is 
facilitated and, when negotiations cease, the invoice is finalized. 

Page 42, Lines 9-19 

Figures 24A and 24B illustrate an illustrative Purchase Order Performa 
Invoice (POPI) V230O24OO. The Purchase Order Proforma Invoice allows a buyer 
to submit an application to initiate a transaction in VTrade electronically on VTrade 
Web. The Buyer indicates the performance by seller or requirement for seller to 
fulfill via POPI. The buyer submits the POPI to VTrade after completing all 
terms/performance required of the seller. Buyer's bank checks and earmarks 
buyer's VTrade line of credit (LOC). Once the LOC is earmarked by the bank, 
confirmation is sent to seller by VTrade. A confirmed/interested seller will negotiate 
sales/purchase terms with buyer using the POPI. The seller will indicate fulfillment 
of the buyer's requirements on a Combined Purchase Order Proforma Invoice. 

Page 42, Lines 21-28 

If the seller cannot fulfill the buyer's requirement, the buyer and seller will 
amend the POPI until agreeable terms are achieved. The buyer and seller can 
submit each amendment on POPI via the submit pushbutton v 23 02 / v 23 0 424fl2 x 
2404 . Each amendment by trading parties on POPI will be reflected as a new 
version. The VTrade Web allows old versions of amendments to be stored and 
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viewed. Once the POPI is finalized, the buyer and seller signs agreement on overall 
terms and conditions of POPI which automatically triggers POPI to be sent to 
VTrade. The seller then proceeds to prepare commercial/trade documents for 
payment. 

Page 44, lines 8-30 through Page 45, lines 1-2 

Figure 27 illustrates the Main Menu Page of an electronic document checklist 
2700 which may be used during the process of Figure 26. The Electronic 
Document Creator (Main Menu) is the front page for the VTrade Electronic 
Document Creator. It is essentially a deal sheet for the buyer and seller to sign on 
once agreement is reached on all documents. The buyer and seller negotiate on 
terms of a transaction using the document creator. By pressing on the icon 2702 
next to the documents indicated, buyer/seller is linked to the next layer which is 
the Electronic Document Creator (Document Page). Once there is agreement on 
the terms of a particular document (refer Document Creator), buyer and seller 
'digitally signs' by selecting an icon 2704 next to the related document on the main 
menu page. The Document Creator (Main Menu) also help track receipt of other 
related physical documents outside VTrade. Scan or 'mirror copies' of these 
documents can be viewed but they are not checked by VTrade Once agreement is 
reached on all documents between buyer and seller, both sign an agreement on 
overall terms and conditions of the Document Creator before submission to VTrade. 
The VTrade Enterprise digitally checks that all electronic documents submitted are 
collected and waits for payment authorization from the bank/buyer before using the 
payment interface to contact Visa net for payment to seller. 

Figure 28 is a flowchart illustrating a process 2800 for creating a financial 
transaction-related document. In operation 2802, a buyer is allowed to select 
among a plurality of documents associated with a proposed transaction. In 
operation 2804, the buyer is permitted to indicate requirements of trade terms 
relating to the selected documents. A seller may agree or amend the terms on an 
electronic document platform in operation 2806. Upon each amendment, a new 
version of a form delineating the trade terms is generated in operation 2808. In 
operation 2810, each of the versions may be viewed. 
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Page 49, lines 16-20 

VTrade should operate under some group of recognized rules, preferably rules that 
are enforceable in foreign countries. Figure 40 illustrates an embodiment of the 
present invention in which VTrade operates under applicable Visa -VISA Card and 
international commerce rules 4000,4002, with an avenue for dispute resolution via 
the ICC international court for arbitration. 

Page 55, lines 1-7 

The present invention is preferably practiced in the context of a vertical market. 
Players with common needs will naturally look to deep vertical eMarketplaces that 
cater to their specific needs. Therefore, horizontal hubs will be challenged to 
directly provide members with targeted industry knowledge and focused offerings. 
Further, fast movers will lock up key suppliers early making room in many market 
segments for only one player, 

Page 67, lines 12-24 

Figure 72 is a flowchart Wustrates- illustrating a process 7200 for initiation of 
an agreement utilizing a network. In operation 7202, a buyer and a seller are 
allowed to negotiate terms of trade utilizing a network. A form is received from the 
buyer in operation 7204 indicating the terms of trade utilizing the network. Also 
received utilizing the network in operation 7206 is an identifier of the buyer. 
Thereafter, the form is sent to a bank in operation 7208 for assessing the credit of 
the buyer utilizing the network. The bank to which the credit application is sent is 
based on the identifier. Next, in operation 7210, the form is forwarded to a seller 
along with the assessment of the credit of the buyer. In operation 7212, the seller 
is permitted to digitally sign the form utilizing the network. The digitally signed 
form is received from the seller in operation 7214 utilizing the network, after which 
a notice is sent to the buyer in operation 7216 indicating that the digitally signed 
form has been received from the seller, thus initiating the agreement. 

Page 71, lines 4-9 
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The purpose of the development environment is to support the tasks involved 
in the analysis, design, construction, and maintenance of business systems, as well 
as the associated management processes. The environment should adequately 
support all ofthe development tasks, not just the code/compile/test/debug cycle. 
Given this, a comprehensive framework for understanding the requirements ofthe 
development environment can be used. 

Page 74, lines 1-3 

• A Responsibility, Accountability, and Authority (RAA) profiles deliverable (-RAA) 
for each role in the Development team, making sure that all the responsibilities 
listed earlier are covered.. 

Page 79, lines 10-13 

The methods of handling media content are somewhat different from those 
surrounding more traditional development content such as code or documentation 
;„for this reason, a role should be defined that is responsible for the management of 
all media content. 

Page 80, lines 16-18 

• Issue Management (decisions to be made regarding the development of the 
business capability, not to be confused with problem management) 

• not to be confused w i th prob l em managem e nt) 

Page 83, lines 9-13 

Just as a business application requires support and system users require 
service, the development environment requires system operations daily, and 
developers require ongoing support in order to use the environment effectively^ (In 
fact, the complexity and frequency of these operations is often greater than that of 
the execution environment). 

Page 108, lines 14-16 
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• Maintain a mix of high-priority and sure successes to ensure the continued 
momentum of the Continuous Improvement program 

• of - th e €of>t i fi u o tiS" I mpr ov eme nt -p r o g ra m 

Page 149, lines 4-8 

The necessity of impact of volume and stress testing early in the 
development process is becoming more common, due to the proliferation of new 
technologies and tools which have little or no performance track record. It is 
important that the performance and reliability of such tools and technologies is-are 
established as early as possible in the project to avoid possible problems further 
down the line. 

Page 175, lines 13-18 

Ihe repository may need to be extended by the Engagement team to support 
custom objects defined by the Application Development team. Some repositories 
support user-defined objects as part of the base functionality. Others allow 
customization of the repository by the user while some are not designed for 
customization at all. If the repository requires extensive customization, a buy 
versus build decision may be required. 

Page 225, lines 19-23 

It is useful for developers to have read-only access to either a hard or soft 
copy of the data model during development. This document rapidly becomes a key 
discussion document in design discussions. It is useful to show tables, columns, 
primary keys, and foreign keys (if all of this will fit on a diagram at the same time!) 
in the document 

Page 239, lines 7-9 

As the number of events increases, the complexity of the event model 
increases and the dia gr a m e r s -dia grams may need to support certain facilities such 
as intelligent connectors. Simple graphics packages may not suffice at this level. 



Docket 60021-339201 



Page 28 



Page 245, line 23 

• C++ - available from 

h tto : //www . u s e r s . cs . urn n . edu/~ kotu lo/cocoon /cocoon . htm 
^usersxs.umn.edu/^kotula/cocoon/cocoon.htm" 

Page 247, lines 4-9 

Caution must be taken not to raise the expectations of the users in terms of 
the length of time it will take for the final product to be delivered. Prototyping will 
deliver something that looks like it "works" very quickly. It should be clear that 
what is delivered is a model and not an application. Clients may expect real 
application functionality to be developed and delivered quickly due to_the fast 
turnaround of the prototyping process, which will invariably not be the case. 

Page 277, lines 3-7 

Frameworks may be found on the market which provide generic components 
for general business processes such as general ledger, sales order processing, 
inventory management or product distribution. For example, IBM San Francisco 
offers business components for the Java environment (see 
httj>r/-/www-.4bmyCom "f see ibm .com/Java/Sanf rancisco)" 

Page 314, lines 2-7 

It is important to note that there may be requirements which cannot be met 
by any tools. In this case, in-house development may be an alternative. This 
approach is likely to be more expensive, however, and more difficult to support the 
long term, and thus should usually be avoided if possible. Wef^Where.possible, 
the tool with the closest match should be purchased, and customized to meet the 
necessary requirements. 

Page 320, lines 12-23 through Page 321, lines 1-8 

Management applications are those tools which are used to manage the 
system. Most of the MODE functions tie directly into this component. The 
management applications component ties in directly with the integration platform 
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component as the management applications tools must comply with the standards 
set by the integration platform. For example, if the integration platform is HP 
OpenView, then the management applications must be HP OpenView software (API, 
SNMPx) or hardware (card) compliant. Management applications receive data from 
the event/data generation, event processing, and repositories components and then 
send data to the presentation or repositories components. Management 
applications tools include capacity planning tools, performance management tools, 
license management tools, remote management tools, systems monitoring tools, 
scheduling tools, help desk tools, etc.. Some Enterprise Management tools even 
poll the event/data generators for information but these options may impact 
network performance. Web Server management is- has been introduced as part of 
the management operations framework. As Corporate Internets and Extranets 
implement Web based software products to sell and advertise business services, 
corresponding administrative, security, event notification and performance 
requirements must be performed similarly for the companies web based system. 
The critical path issues for Web based server software is typically security and 
performance based levels of service. 

Page 328, lines 18-20 through Page 329, lines 1-2 

Recovery capabilities span the range from those required to bring up a device 
after it has failed to those required in the event of a major disaster. With critical 
business applications being rolled out on distributed technologies, the recovery of 
these systems must be easy, quick and efficient. Loss of the system for even a 
short period of time can result in significant financial losses to a cH e nt s- dient's 
business. 

Page 332, lines 8-10 

Production Scheduling contains specific requirements that addresses a 
distributed environments environment's complexity of multiple platforms and 
system placed in either a parallel or serial fashion. 

Page 338, lines 10-13 
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File Transfer and Control initiates and monitors files being transferred 
throughout the system as part of the business processing (e.g., nightly batch runs). 
File transfers may occur between any two or more dev i s e s devices within the 
system. 

Page 343, lines 19-21 

Additional facilities may be required, even al though- th i oug h. da ta bases 
typically have built-in utilities or tools to perform these function and do not 
generally require a separate tool. 

Page 344, lines 17-21 

Files that are either unique, store site specific data or are highly volatile 
should be backed up. This will help ensure that important, business critical data 
will not be lost in the event of a system failure or disaster. All files do not 
necessarily need to be backed up as each file backup utilizes storage space and ma 
mayjmpede the performance of the system. 

Page 373, lines 13-15 

It may be appropriate to control assets within the first stage of the life 
cycle(i.e., from development on) or it my-may prove more appropriate to 
implement Asset Management only from the point of delivery. 

Page 379, lines 2-5 

Continuous monitoring can generate significant performance overhead, 
whereas targeted, periodic monitoring may only be necessary. This strategy will 
impact the design of the technical infrastructure as well as the tools chosen the-tQ 
manage the systems performance. 

Page 383, lines 17-20 through 384, lines 1-6 

The design of the test environment should reflect the production environment 
as closely as possible. In principle it is desirable to have an identical set up in both 
environments. However, this may be cost prohibitive and some parts of the 
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configuration may not be critical to business. The contents of the test environment 
therefore need to be decided. Yet it is difficult to judge which components of a 
distributed environment may actually impact services. For example, networking 
components, such as bridges, are often seen as transparent and not required in a 
test environment, which my -may mean that several LANs in production are only 
reflected by one LAN in the test environment. The risk of adopting this approach 
must be addressed thoroughly, and should be approved be~by.senior management. 

Page 390, lines 2-3 

Involves the detection and correction of faults within the system whether 
they be minor (e.g., workstation is down) or major (he ve.g. , a disaster) has 
occurred. 

Page 430, lines 10-17 

Netscape, FireFly Network Inc. and VeriSign have introduced Open Profiling 
Standard (OPS)/ a proposed standard that helps to address the issues of multiple 
profiles. This proposed standard would provide Internet site developers with a 
uniform way of getting users' Personal Profile information in order to personalize 
interaction. The OPS is a standard being worked on as part of the World Wide Web 
Consortium's Platform for Privacy Preferences- ■ ( ■ http://www . w3 c.org ) "(w3c.orQ)" . 
It is compatible with the existing vCard and X.509 digital certificate technology 
standards, which allow for user identification and authentication over the Web. 

Page 448, lines 5-11 

The normal delivery method of the content is through the use of HTTP. This 
method will be used to deliver the majority of the content. There are other 
methods of delivery that may be considered depending upon the content to be 
delivered. Other delivery methods incl-udes- include e-mail, FTP, Push or Channels 
and streaming video. Since timing of the delivery is very important, consideration 
must be given to developing a method of delivery that provides the most impact to 
the user and does so in a timely manner. 
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Page 453, lines 7-13 

• Usage Metering and Reconciliation. There are different methods 

for billing for advertising space. The most common billing methods are usage 
which may include: the number of times displayed, the length th e add added 
is displayed or the number of users to which the ad is displayed. Services 
are needed to record the usage information in order to reconcile with the 
advertisement providers. Since many sites are funded by ad revenue, the 
accuracy of these services is crucial. 

Page 484, lines 1-3 

V4sa -VISA ©and Master€ard MASTERCARD © have jointly developed the Secure 
Electronic Transaction (SET) protocol to allow secure, cost-effective bank-card 
transactions over open networks. SET includes facilities for: 

Page 484, lines 7-10 

Consumers get their encryption keys using a specific program integrated into 
their browser. This program automatically converts a consumer's credit card 
number into a certificate given by V+sa-VISA. or M a st G rG a rd MASTERCARD. This 
certificate contains a key and will be attached permanently to the browser of the 
consumer. 

In The Claims 

Please amend claims 1, 7 and 13 as follows: 

1. (Amended) A method for initiation of an agreement utilizing a network, 
comprising the steps of: 

(a) allowing a buyer and a seller to negotiate terms of trade utilizing a network; 

(b) receiving from the buyer a form indicating the terms of trade utilizing the 
network; 

(c) receiving an identifier from the buyer utilizing the network; 

(d) sending the form to a bank for assessing the credit of the buyer utilizing the 
network, wherein the bank to which the credit application is sent is based on 
the identifier; 
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(e) forwarding the form to a t he seller along with the assessment of the credit of 
the buyer utilizing the network; 

(f) allowing the seller to digitally sign the form utilizing the network; 

(g) receiving the digitally signed form from the seller utilizing the network; and 

(h) transmitting a notice to the buyer indicating that the digitally signed form 
has been received from the seller, thus initiating the agreement. 

7. (Amended) A computer program embodied on a computer readable medium 
for initiation of an agreement utilizing a network, comprising: 

(a) a code segment for allowing a buyer and a seller to negotiate terms of trade 
utilizing a network; 

(b) a code segment for receiving from the buyer a form indicating the terms of 
trade utilizing the network; 

(c) a code segment for receiving an identifier from the buyer utilizing the 
network; 

(d) a code segment for sending the form to a bank for assessing the credit of the 
buyer utilizing the network, wherein the bank to which the credit application 
is sent is based on the identifier; 

(e) a code segment for forwarding the form to a the seller along with the 
assessment of the credit of the buyer utilizing the network; 

(f) a code segment for allowing the seller to digitally sign the form utilizing the 
network; 

(g) a code segment for receiving the digitally signed form from the seller utilizing 
the network; and 

(h) a code segment for transmitting a notice to the buyer indicating that the 
digitally signed form has been received from the seller, thus initiating the 
agreement. 

13. (Amended) A system for initiation of an agreement utilizing a network, 
comprising: 

(a) logic for allowing a buyer and a seller to negotiate terms of trade utilizing a 
network; 
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(b) logic for receiving from the buyer a form indicating the terms of trade 
utilizing the network; 

(c) logic for receiving an identifier from the buyer utilizing the network; 

(d) logic for sending the form to a bank for assessing the credit of the buyer 
utilizing the network, wherein the bank to which the credit application is sent 
is based on the identifier; 

(e) logic for forwarding the form to a-the.seller along with the assessment of the 
credit of the buyer utilizing the network; 

(f) logic for allowing the seller to digitally sign the form utilizing the network; 

(g) logic for receiving the digitally signed form from the seller utilizing the 
network; and 

(h) logic for transmitting a notice to the buyer indicating that the digitally signed 
form has been received from the seller, thus initiating the agreement. 
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